Conversation
| * | ||
| * @return array|string|int|null | ||
| */ | ||
| public function getIdentifier(): array|string|int|null |
There was a problem hiding this comment.
The one not so nice thing about such a generic api is that array|scalar is always an issue for any app usage, in regards to developer or static analyzers.
Would be nice if there was a more concrete API to either get scalar or not, I always end up having to inline annotate everything that has such an API
- getScalarIdentifier()
- getArrayIdentifier() / getCompositeIdentifier()
etc as idea.
But I guess that is out of scope here. So no objections from me, just this remark.
There was a problem hiding this comment.
The array part of this type is the problem imo. We've inherited that from the ORM though because we need to support composite primary keys 😢
There was a problem hiding this comment.
Yeah the returns types are due to the possible pK values types. Addressing that would be a separate issue.
There was a problem hiding this comment.
Well, there is an option to separate here as by my proposal, throwing exception in the other case.
Removing the need to delegate this check to the consumer.
But as mentioned, nothing that is important at this point. Just a though.
There was a problem hiding this comment.
If we did narrow types here wouldn't we be left with partial support for composite primary keys? While the types are a bit annoying, I'd rather we have consistent support for composite primary keys over ergonomic types in one method.
3 participants
If you just need that id/identifier then using this new method would be more convenient than doing
$this->Authentication->getIdentityData('id')(which can throw an exception) or doing$this->Authentication->getIdentity()?->getIdentifier().